home *** CD-ROM | disk | FTP | other *** search
- Editor's Note: Minutes received 11/24/92
-
- CURRENT_MEETING_REPORT_
-
- Reported by Martha Steenstrup/BBN
-
- Minutes of the Inter-Domain Policy Routing Working Group (IDPR)
-
- At the November 1992 IETF meeting, the IDPR Working Group met for two
- consecutive sessions during the afternoon of Monday the 16th. The first
- session was a working meeting, while the second session was conducted as
- an overview for newcomers. We organized the first session as follows:
-
-
- 1. General Status Report
-
- o The IESG and IAB accepted the IDPR architecture and protocol
- documents as Proposed Standards in August 1992.
-
- o SRI is expecting to implement a large part of the IDPR MIB.
-
- o Rob Austein has designed the the DNS changes (address to domain
- identifier mapping queries and responses) required for IDPR.
-
- o We are seeking eager volunteers to produce an independent
- implementation of IDPR.
-
- 2. Gated version of IDPR
- Woody Woodburn of Sparta led the gated implementation effort, with
- additional participation by BBN. SRI is presently using the gated
- version of IDPR as the basis for policy routing in a network for
- one of their clients. Currently, SRI and BBN are taking
- responsibility for the IDPR gated software. We will eventually
- turn over the gated version of IDPR to Cornell, but before doing
- so, we need to ensure that the software:
-
- o Conforms to the protocol specification.
- o Has clear and complete documentation.
- o Has been tuned to provide good performance.
-
- We welcome all those interested in working on the IDPR gated
- software or in developing their own IDPR implementations. Please
- send a message to idpr-wg@bbn.com, if you're interested in working
- on IDPR software development.
-
- 3. Planned Internet Pilot Installation
- The target date is February 1993. The installation will initially
- include three backbone domains (NSFnet, NSInet, and TWBnet) and
- four source domains. We will exercise both source and transit
- policies. This will give transit service providers a chance to
- observe IDPR in action. The results of the pilot installation,
- including ease of use and management, general performance, and any
- problems encountered, will be published as an Internet-Draft.
-
-
- 1
-
-
-
-
-
- 4. Policy Survey
- The policies initially available with IDPR were extrapolated from a
- survey of federal agencies conducted several years ago. As IDPR
- moves from the testbed to the Internet, we should reevaluate the
- policy support provided. We intend to conduct a systematic survey
- of users and transit service providers to determine what types of
- source and transit policies are most desired. Results of this
- survey will be folded back into the policy offerings within IDPR.
- Anyone interested in helping to conduct the survey, please respond
- to the idpr-wg mailing list.
-
- 5. Multicast IDPR
- To provide multicast support in an internetwork in which policy is
- important, one cannot leave the forwarding decisions to
- intermediate routers. Rather multicast distribution should be
- defined by the source, just as it is for unicast distribution. To
- provide multicast support within IDPR, we plan to make the
- following modifications to IDPR:
-
- o All multicast groups of which hosts within a domain are members
- will be distributed as part of the existing routing information
- messages for the domain. This information will be used by a
- source to generate a multicast tree to other members of a
- multicast group.
-
- o The path identifier will carry a special multicast bit
- indicating that it is a multicast packet. All paths in a
- multicast tree will carry the same path identifier.
-
- o One or more path setup packets will be used to set up the
- multicast tree in sections or all at once. Each intermediate
- policy gateway in a path must keep track of all of the
- destination domains in the multicast tree that are reachable
- through the subtree of which it is the root.
-
- o The source will be notified through a teardown message when all
- hosts within a domain leave a the multicast group. The
- teardown will only affect the portion of the tree set up to
- that domain. A source should be able to initiate teardown to
- selected destinations or to all destinations within a multicast
- tree.
-
- o Intra-domain multicast, when available, will be used in
- conjunction with IDPR multicast.
-
-
- In early 1993, we will distribute an Internet-Draft describing the
- initial version of multicast routing for IDPR.
-
- Attendees
-
- Cengiz Alaettinoglu ca@cs.umd.edu
-
- 2
-
-
-
-
-
- Ken Carlberg Carlberg@cseic.saic.com
- Dilip Chatwani dilip@synoptics.com
- Osmund de Souza osmund.desouza@att.com
- Barbara Denny denny@erg.sri.com
- Paul Griffiths griff@chang.austin.ibm.com
- John Hedderman jjh@ans.net
- Jonathan Hsu brenda@penril.com
- Dwight Jamieson djamies@bnr.ca
- Fong-Ching Liaw fong@eng.sun.com
- Olli-Pekka Lintula olli-pekka.lintula@ntc.nokia.com
- Peder Norgaard pcn@tbit.dk
- John Scudder jgs@merit.edu
- William Simpson Bill.Simpson@um.cc.umich.edu
- Lansing Sloan ljsloan@llnl.gov
- Frank Solensky solensky@andr.ub.com
- Martha Steenstrup msteenst@bbn.com
- Robert Woodburn woody@sparta.com
-
-
-
- 3
-